房产经纪SaaS系统 · 在线签约功能

最后更新 · 2026/09/11

文档版本: v12.0
更新日期: 2026-06-24
最后更新: 2026-06-24
状态: v12.0 重构版，完成业务流深度优化与安全锁约束统一

文档阅读指南

角色	核心阅读章节	关注重点
产品经理	第一部分(业务全景) + 第四部分(签约执行与安全锁)	状态机流转、用印安全锁逻辑、合规风险控制
前端开发	第五部分(全端交互规范) + 第六部分(验收标准)	UI结构、动态隐藏与显隐联动、CSS规范与Tab标识
后端开发	第三部分(发起签约) + 第四部分(安全锁) + 第六部分(验收标准)	三要素接口核验、物理撤销机制、API权限、数据一致性
测试工程师	第四部分(状态流转) + 第六部分(验收标准)	异常场景测试用例、边界条件校验、风控拦截路径

第一部分：业务全景与时序

一、项目背景与设计目标

1.1 背景说明

当前房产经纪SaaS系统支持二手房买卖、房屋租赁两大业务。经纪人在系统中完成交易撮合后，需要线下打印、手动签署居间合同及佣金确认书，流程效率低下且存证法律风险高。为实现合同全程数字化存证、提升签约效率、规避法律合规风险，系统全面接入e签宝电子签名服务(SaaS API V3版)，在SaaS系统内直接发起、管理在线电子签约全生命周期。

1.2 核心目标

效率提升：将签约周期从1~3天压缩至当日完成，支持远程异地签署。
合规存证：电子合同具备完整法律效力，签署过程全程存证并记录于司法区块链。
用印风控：建立严格的内部审批与用印联动，杜绝“未批先盖”和越权用印。
流程完备：支持合同发起、催签、延期、修正重发、补充协议变更以及解除作废等全套闭环功能。

二、系统集成拓扑架构

SaaS系统与e签宝开放平台通过加密 HTTPS API 和 Webhook 回调进行双向通信，其系统集成关系如下：

┌─────────────────────────────────────────────────────────────────────┐
│                       房产经纪 SaaS 系统                              │
│                                                                     │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐  │
│  │  房源管理模块  │  │  客户管理模块  │  │       成交/签约模块        │  │
│  └──────────────┘  └──────────────┘  └────────────┬─────────────┘  │
│                                                    │                │
│  ┌─────────────────────────────────────────────────▼────────────┐  │
│  │                      在线签约功能引擎                           │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────────┐  │  │
│  │  │签约主体维护│  │合同模板管理│  │签约配置管理│  │   审批流系统   │  │  │
│  │  └──────────┘  └──────────┘  └──────────┘  └──────────────┘  │  │
│  │  ┌─────────────────────────────────────────────────────────┐  │  │
│  │  │              签约发起与执行控制                             │  │  │
│  │  │  信息录入 → [三要素强核验] → e签宝发起 → [用印安全锁] → 归档│  │  │
│  │  └─────────────────────────────────────────────────────────┘  │  │
│  │  ┌─────────────────────────────────────────────────────────┐  │  │
│  │  │              合同管理中心 (PC/移动端)                      │  │  │
│  │  │  列表 | 详情 | 催签 | 修正三要素 | 撤回重签 | 签署变更/解约 │  │  │
│  │  └─────────────────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────┬───────────────────────┘
                                              │ HTTPS API & Webhook
                                       ┌──────▼──────┐
                                       │  e签宝开放平台  │
                                       │ SaaS API V3  │
                                       └─────────────┘

三、核心业务流程图

3.1 首次签约完整流程

首次签约流支持「先审后签」与「先签后审」两种模式。

flowchart TD
    A[经纪人录入成交信息与三要素] --> B{SaaS前置三要素同步核验}
    B -->|校验不通过| C[强阻断: 提示修正三要素并拦截提交]
    C --> A
    B -->|校验通过| D{读取门店配置: 签署顺序}
    
    D -->|先审后签 approve-first| E[发起内部审批流]
    E -->|审批通过| F[调用e签宝API创建签署流程]
    E -->|审批驳回| G[主合同包状态转已驳回 rejected]
    
    D -->|先签后审 sign-first| H[调用e签宝API创建签署流程]
    H --> I[推送外部客户签署，同时激活内部审批流]
    
    F --> J[外部客户完成实名签署]
    I --> J
    
    J --> K{签署模式判定}
    K -->|先审后签+自动落章| L[系统调用自动落章，合同包归档 completed]
    K -->|先审后签+手动落章| M[激活盖章人收到待办，确认用印归档 completed]
    K -->|先签后审| N{手动用印安全锁校验: 内部审批是否已同意}
    N -->|已同意| O[允许激活盖章人手动用印，合同包归档 completed]
    N -->|未通过/审批中| P[安全锁强拦截: 禁止手动落章，按钮置灰]

3.2 合同变更与解约业务流程 (补充协议/解除协议)

补充协议变更与解除协议流程强制要求“先审批后签约”，杜绝外部越权产生法律纠纷。

flowchart LR
    A[已完成合同 completed] --> B{经纪人发起申请}
    B -->|申请变更| C[发起补充协议审批流]
    B -->|申请解约| D[发起解除协议审批流]
    
    C -->|审批驳回/撤销| E[恢复原合同 completed 效力不变]
    C -->|审批通过| F[调用e签宝发起补充协议签署]
    F -->|各方签署完成| G[归档补充协议，合同恢复 completed 标记已附带补充]
    F -->|客户拒签/超期| E
    
    D -->|审批驳回/撤销| E
    D -->|审批通过| H[调用e签宝发起解除协议签署]
    H -->|各方签署完成| I[原合同与解除协议均标记为 voided 并加盖已解除水印]
    H -->|客户拒签/超期| E

第二部分：前置准备与策略配置

四、签约主体与授权盖章人管理

4.1 签约主体维护

企业资质录入：系统支持维护多个丙方签约主体，包括企业名称、统一社会信用代码、法人姓名、法人身份证及法人电话。
主体认证状态：
- 待法人确认：新增主体录入后，状态强制初始化为“待法人确认”。系统将向法人发送短信确认短链，法人点击确认后，状态转为已启用。对于该状态的主体，系统提供“短信催办法人”的催办交互动作。
- 已启用：法人确认激活后，状态自动变更为已启用，方可用于发起签约。
- 已禁用：管理员可手动停用主体，停用后不可用于发起新签约。

4.2 盖章授权人控制

单一激活原则：每个签约主体可配置多名盖章授权人（姓名、手机号、身份证号），但同一时刻仅能有一名激活授权人。只有激活授权人拥有手动落章确认权限。
授权状态流转：新增授权人一律强制为 待法人确认 状态。系统向法人发送授权确认短信，必须由法人确认通过后，方可变更为 已授权。非已授权状态的盖章人无法被设为激活人。列表为待法人确认的盖章人提供“短信催办法人”的操作通道。
撤销与恢复：管理员可在本地系统撤销某人的盖章人授权（状态变为 已撤销）。若恢复授权，可即时将状态改为 已授权。
指派切换与日志审计：切换激活人时，系统会弹出确认框，并且在切换成功后自动将该主体下所有进行中且等待手动落章的签署任务重新指派给新的激活人，并在审计日志中强留痕。

五、合同模板分类维护与自定义字段

5.1 模板分类

系统要求模板管理员在上传合同时必须指定以下11大合同类型之一：

sale_main (买卖居间主合同)
sale_commission_seller (卖方佣金确认书)
sale_commission_buyer (买方佣金确认书)
sale_loan_service (贷款服务确认书)
sale_supplement (买卖补充协议)
sale_void (买卖合同解除协议)
rental_main (租赁居间主合同)
rental_commission_landlord (房东佣金确认书)
rental_commission_tenant (租客佣金确认书)
rental_supplement (租赁补充协议)
rental_void (租赁解除协议)

5.2 列表降噪与详情下沉

主列表降噪：模板主表格中不再展示“签约主体”及“授权盖章人”等高噪信息。
反向数据匹配：管理员在详情中点击“预览正文”时，系统动态展示该模板目前已被哪些签约主体所关联，以及各主体的默认盖章授权人。

5.3 模板自定义动态字段输入规则

字段数量动态合并：在成交发起页面，展示的模板自定义字段表单项数量取决于当前生成的整个合同包中所有子合同去重后的字段总数。
自动生成标识：用户仅需录入自定义字段的中文名称，系统自动将其转换为数据绑定标识（如中文名“交房日期”自动匹配模板占位符 {自定义.交房日期}），严禁强迫用户输入英文标识。

六、门店电子签约策略配置

6.1 门店配置与联动控制

管理员在管理后台的门店电子签约配置页中，对各门店单独维护以下规则：

电子签约功能开关：控制该门店是否允许发起在线签约。
签署顺序模式：可选择“先审批，后签约”或“先签约，后审批”。
自动落章规则：
- 模式选择为“先审批，后签约”时：落章规则可选择“自动落章”或“手动落章”。
- 模式选择为“先签约，后审批”时：落章规则强制锁定为“手动落章”，且置灰禁用“自动落章”单选框。

6.2 签署限制参数

签署有效期：参数配置范围强制限制在 1~30天，默认7天。
催签频次风控：两次催签之间的最小间隔强制限制不低于 2 小时，且配置 of 单日最大催签次数不得为负数。

第三部分：发起签约流规范

七、买卖与租赁合同包生成规则

7.1 二手房买卖合同包生成矩阵

经纪人录入成交信息和佣金后，系统自动依下表生成子合同清单并打包发送：

佣金填写情况	贷款服务费金额	生成子合同清单
甲方佣金 > 0 且乙方佣金 = 0	0 元	① 居间合同 (三方)② 卖方佣金确认书 (丙+甲)
甲方佣金 = 0 且乙方佣金 > 0	0 元	① 居间合同 (三方)② 买方佣金确认书 (丙+乙)
甲方佣金 > 0 且乙方佣金 > 0	0 元	① 居间合同 (三方)② 卖方佣金确认书 (丙+甲)③ 买方佣金确认书 (丙+乙)
甲方佣金 > 0 且乙方佣金 > 0	> 0 元	① 居间合同 (三方)② 卖方佣金确认书 (丙+甲)③ 买方佣金确认书 (丙+乙)④ 贷款服务确认书 (丙+乙)
双方佣金及服务费均为 0 元 (双零规则)	-	允许发起签约，仅生成居间合同 (三方)，不生成任何佣金确认书 (适用于无佣金或线下结算场景)

7.2 房屋租赁合同包生成矩阵

租赁佣金折算百分比四舍五入保留两位小数，公式：(佣金金额 ÷ 单月租金) × 100%。

佣金填写情况	生成子合同清单
房东佣金 > 0 且租客佣金 = 0	① 租赁主合同 (三方)② 房东佣金确认书 (丙+甲)
房东佣金 = 0 且租客佣金 > 0	① 租赁主合同 (三方)② 租客佣金确认书 (丙+乙)
房东和租客佣金均 > 0	① 租赁主合同 (三方)② 房东佣金确认书 (丙+甲)③ 租客佣金确认书 (丙+乙)
房东和租客佣金均为 0 元	允许发起签约，仅生成租赁主合同 (三方)

7.3 免责性绝对金额明示

所有涉及佣金折算百分比的子合同模板中，系统在渲染百分比折算值时，必须在模板中自动渲染如下强制声明：

“注：本合同/确认书内百分比折算仅供参考，各方具体结算收付金额以本确认书内载明的绝对货币金额为准。”

八、三要素前置同步核验机制 (强阻断无强发)

核验时机：在经纪人填写完交易双方的姓名、手机号、身份证号并点击“发起签约”时，系统即时同步调用e签宝三要素核验接口 (POST /v3/auth/individual/verify)。
强阻断机制：
- 核验成功：正常流转，生成 PDF 并发起后续审批或签署流程。
- 核验失败：强行拦截报错并阻断提交，绝对不允许以任何参数绕过校验强行提交。系统退出发起流程，数据保留为草稿，提示用户核实三要素无误后重新提交。
降级与防灾控制：如果三要素核验接口调用超时（10秒）或服务不可用，系统提示“核验服务暂不可用，请稍后重试”并强行拦截，严禁自动降级放行。

九、签署中异常状态自助修正重发机制

在合同包已发起并进入“签约中 (signing)”阶段后，如果在外部用户真正签署时，因用户过户、销户、更名或发生手机号码归属转移，导致e签宝实名认证流程失败卡死时，系统提供完整的签署中自助纠错流程：

异常状态转换：e签宝回调实名失败，或用户上报卡死，系统将合同包状态变更为 auth_failed（三码不一致），合同管理列表中高亮为 三码不一致。
常规按钮锁定：常规催签、预览按钮隐藏，仅保留**「修正三要素并重发」**操作。
自助修改与进度重置强提示：
- 经纪人点击按钮弹出修改框，修改不一致的三要素信息。
- 用户提交修改时，系统必须弹出强警告对话框：
  
  “注意：由于修正了三要素，系统将重新渲染合同PDF文件。本次操作成功后，该合同在e签宝端的签署进度将彻底重置，之前所有签署方的签署记录均会作废，均需要重新签署新合同文件。是否确认继续重发？”
- 经纪人确认后，系统再次调用三要素核验，校验通过后重新生成 PDF 文件并重置签署任务（生成新签署链接），合同包状态变回 signing。

第四部分：签约执行与用印安全锁

十、先审后签与先签后审落章机制

10.1 先审后签模式

内部会签/或签审批全部通过后，系统调用接口开启外部签署。当外部甲乙方签署人完成电子签署后，系统根据配置自动完成落章，或通知授权人手动落章，流转至 completed。

10.2 先签后审模式

系统直接调用e签宝发起签署并向甲乙方推送链接，同时激活内部审批流。客户签署的内容在内部终审通过并由丙方加盖公章前，在法律上是不生效的。

十一、内部审批决策流 (会签一票否决与加签)

会签一票否决：会签节点中只要有一个审批人驳回，整个审批流直接被驳回，状态流转至 rejected，且其余未审批人员的待办任务自动取消。
审批加签控制：
- 前加签：将加签人插入当前节点之前，当前审批人审批权限隐藏，需等前加签人通过后才可重新获得审批权。前加签人若驳回，流程直接终止。
- 后加签：将加签人插入当前节点之后，不影响当前审批人审批。

11.1 通用审批流规则可视化配置与编排

为了实现各门店签约、解约、变更（修改）审批流的精细化定制，系统提供可视化编排看板，支持系统管理员在后台针对不同门店类型配置审批规则。规则包括以下具体规范：

适用范围与门店排他性规则：
- 适用范围可选择“全局规则”或指定一至多个门店。
- 门店唯一性原则：对于同一种审批类型（签约审批、解约审批、补充协议审批），每一个门店只允许被绑定到一个审批规则中。
- 新增或编辑审批规则时，已被其他规则绑定的门店在下拉选择菜单中应自动置灰并禁用；若已存在其他同类型的“全局规则”配置，则“全局规则”均自动禁用，避免配置冲突。
审批人角色与人员设置：
- 部门角色：若选择“部门角色”，审批人默认强制为该门店的“门店管理员”，无需（也不允许）再进行其他角色类型的选择。多人审批选项（或签/会签）始终保留并保持启用。
- 指定人员：若选择“指定人员”，下拉多选列表中的候选人员必须根据当前选定的“适用范围”联动拉取（若为“全局规则”拉取全公司所有人，若为指定门店则只拉取隶属于已勾选门店的人员）。
- 多人审批显隐控制：当指定人员只勾选了 1 人时，隐藏多人审批选项；勾选了 2 人及以上时展示该多人审批单选框（可选择或签/会签）。
抄送配置多选与组织架构分组：
- 抄送设置去除了“部门角色”选项，仅支持“不抄送”和“指定人员”。
- 当选择“指定人员”时，交互界面展示全公司所有人员的复选框列表，且按照门店/组织架构进行分类展示，支持多选抄送人员，方便进行全局跨门店批量抄送通知。
范围改变时的联动清退机制：
- 当编辑中的“适用范围”发生变更时，当前已配置的节点审批人信息（指定人员）应自动进行合法性校验，清退非该范围的员工，防止跨店越权审批（抄送人因支持全公司全局选择，故不受此清退限制限制）。

十二、用印安全锁：先签后审手动落章强校验控制

[!IMPORTANT]

为防止“先签后审”模式下，审批流被驳回但企业公章已被加盖导致越权履约纠纷，系统底层设计强制用印安全锁。

手动用印校验锁：当合同包采用“先签后审”模式时，外部客户均已签署完毕，合同包等待丙方落章（状态处于 signing）。此时激活的授权盖章人在详情抽屉点击“手动用印”时，系统必须即时检测该合同包关联的内部签约审批流状态。
拦截规则：
- 若审批流处于 approving_new（审批中）或已驳回 rejected：系统必须强行拦截用印，禁止调用e签宝加印接口，且前端“手动用印”按钮应呈现置灰状态，Hover时显示提示文案：“内部审批流程尚未通过，用印已安全锁定！”
- 若审批流已终审通过（状态为 approved）：允许激活盖章人通过人脸核验后，正常调用e签宝API进行手动落章。

十三、中途撤销与已签状态下的物理作废机制

中途撤销流程：在丙方最终落章完成、合同包归档为 completed 前，经纪人若点击“撤回重签”，系统必须调用e签宝撤销接口 (POST /v3/sign-flow/{flowId}/revoke) 撤销签署流程。
物理废止：撤回成功后，e签宝端所有的签署链接自动失效，外部客户已签署的电子签名在e签宝平台被物理作废，合同包在本地变更为已撤销 revoked。若检测到已有一方签署，撤回时强制要求输入不少于5字的撤回原因。

十四、合同变更(补充协议)与合同解约(解除协议)流程

已完成合同禁止改写：处于 completed 状态的合同包绝对禁止任何原PDF物理改写。
申请变更（补充协议）：
- 发起申请后状态转为 approving_modify。审批通过后，系统调用e签宝API**创建全新的补充协议签署流程（生成新 flowId）**推送签署。
- 多补充协议动态生成与签署规则：补充协议的发起签署与归档是根据合同变更维护弹窗中勾选需要签署的子合同数量和名称动态决定的。勾选几份，系统底层即动态生成并呈递几份专属的补充协议书（如《xxx》补充协议书），不支持统一写死为单份。
- 签署完成归档至原合同包，主状态回滚为 completed，详情标注“已附带补充协议”。若签署中途发生拒签或超期，补充协议物理作废，原合同法律效力维持原状不变。
申请解约（解除协议）：
- 发起申请后状态转为 approving_void。审批通过后，创建全新的解除协议流程。
- 双方在e签宝完成签署后，系统自动将原合同包及解除协议本地状态更新为 voided（已作废）。系统自动在本地 PDF 副本每一页加盖“已解除VOID”防伪水印，解除房源锁定。
双端文件展示过滤与多文件呈现规范：
- 在桌面端详情抽屉及移动端合同详情页中，当切换至“合同变更/变更协议”或“合同解约/解约协议”子选项卡（Tab）后，文件展示页面严禁展示原合同正文内容，必须且仅能展示对应的补充协议或解除协议。
- 对于补充协议，在详情文件列表区及对应的审批详情“待签署的新协议文件”列表中，必须支持循环动态渲染展示多份对应的补充协议预览入口，确保能够根据勾选的子合同数呈现对应的多份补充协议卡片并支持独立预览。

第五部分：全端合同与审批交互规范

十五、桌面端合同管理中心与详情抽屉交互

15.1 详情抽屉版式与滚动区域

布局结构：详情抽屉采用上下分域设计。包含房源/成交头信息、全局主切换Tab（1. 合同预览和签字进度、2. 审批进度、3. 操作记录和日志）等成交核心元数据保持固顶不参与纵向滚动；其下方的合同PDF在线预览、审批时间轴以及操作日志等内容区，必须支持单独的纵向滚动，避免主抽屉页面的视觉高度塌陷。

15.2 详情子页签与显示模式

页签匹配：在“合同预览和签字进度”Tab下，提供 首次签署(first)、合同变更(modify)、合同解约(void) 三个子页签。
交互规则：系统需根据合同当前的生命周期状态（例如是否发生过变更或解除协议），动态显隐匹配对应的子页签内容，并且确保预览与签字进度模块的正常排版渲染，无视觉遮挡和文字溢出。

十六、移动端合同与审批管理交互

16.1 页面排版与跳转

全屏跳转：移动端合同详情、审批详情、审批决策及意见输入，必须使用全屏跳转页面方式承载，返回时提供标准的左上角导航返回按钮；严禁使用底部弹出抽屉来承载全页面级的数据和表单。

16.2 底部操作按钮与延期交互

按钮展现：移动端合同详情页底部的核心业务操作按钮采用扁平化网格布局，纯文字展示并去除所有 icon 图标，提高触控交互面积。
天数延期展示规则：
- 点击“延期”后，底部弹出快捷天数选择面板（提供 3天、7天、15天选项）。
- 动态天数计算校验：系统计算 当前时间 + 选择 the 延期天数 - 发起时间，若超出30天限制，对应的按钮不予显示。若全部超出，则天数选项置灰禁用并提示已达上限。

十六点五、桌面端全局操作日志审计中心交互规范

16.5.1 高危审计事件微型看板

展示要求：位于页面顶部，以卡片形式直观统计今日（包含累计预置演示数据）的以下高危指标，辅助法务合规人员快速宏观感知：
- 今日三要素失败阻断：统计今日核验失败的阻断次数（对应 AUTH_FAILED）。
- 今日中途撤回重签：统计已有人签字但强行撤销的次数（对应 REVOKE）。
- 今日签约审批驳回：统计审批被直接驳回的次数（对应 REJECT）。

16.5.2 复合过滤检索

筛选维度：
- 合同编号：支持模糊输入过滤。
- 操作人姓名：支持模糊输入（如员工姓名、系统自动、e签宝回调等）。
- 操作动作类型：下拉选择特定的动作（如 INITIATE, SEAL 等）。
- 安全哈希校验：下拉筛选“全部状态”、“哈希校验通过（安全）”和“哈希检测异常（可能遭数据库物理篡改）”。

16.5.3 日志数据表格与防篡改警告

表格字段展现：日志ID、操作时间（精确到秒）、操作主体（包含员工姓名、角色、所属部门）、关联合同包ID、操作动作类型、状态跳变、操作终端 (IP/设备)（用以物理定位客户端指纹）、详细描述、防篡改哈希。
物理防篡改标识：在“防篡改哈希”列中，系统必须自动在 Hash 值前加塞校验图标：
- 正常未篡改日志：显示 绿色盾牌 标识，鼠标悬浮提示“哈希校验一致，日志安全未篡改”。
- 检测到篡改的异常日志：行背景高亮标红警告，并加塞 红色警报 标识，提示“防篡改哈希校验失败，该行数据已被物理篡改！”。

16.5.4 CSV 报告审计导出

审计归档导出：提供“导出CSV审计报告”按钮。点击后自动导出包含上述所有列表字段以及哈希原文的 CSV 数据，首部需附带 BOM 头以杜绝 Excel 中文乱码。

第六部分：技术指标与质量验收标准

十七、操作日志存证与哈希防篡改规范

SaaS 系统中合同的每一次重要流转（发起、审批通过/驳回、撤销、延期、三要素修正）均必须实时存证入库：

数据结构：包含日志ID（自增）、操作时间（毫秒）、操作主体（Operator）、关联实体（Entity）、操作动作（Action）、详细描述、状态变更（before -> after）以及安全校验码（Hash）。
安全哈希（Hash）防篡改：
- 每一行日志在写入数据库时，系统自动对 日志ID + 操作时间 + 操作人ID + 动作名称 + 详细描述 + 状态变更 + 盐值 组装为字符串，生成 SHA-256 签名存入 Hash 列。
- 系统后台配置定时巡检服务，自动重算哈希值并与 Hash 列对比，一旦不一致立即发送邮件和系统级警报，防止数据库行数据在物理层面被篡改或删除。

17.1 操作日志审计流水内容清单与具体描述规范

(1) 每一条操作日志必须包含的基础字段类型

操作时间：精确到秒（格式为 YYYY-MM-DD HH:mm:ss）。
操作主体（Operator）：部门 + 角色 + 姓名（如：平安路门店 - 经纪人 - 张三；若为系统自动触发则为 系统自动 或 e签宝回调）。
动作类型（Action）：用于后台审计分类（如 INITIATE, AUTH_FAILED, APPROVE, DELAY, REVOKE, SIGN 等）。
详细描述（Description）：面向用户和审计方的易读文字。
状态变更（State Change）：格式为 变更前状态 -> 变更后状态。

(2) 审计流水日志具体触发场景与文案模板一览

业务大类	触发动作 (Action)	状态变更 (State Change)	详细描述文案模板
发起签约类	`INITIATE`	`(空) -> approving_new` 或 `signing`	`发起了在线签约申请，系统已自动锁定房源 [房源地址]。`
三要素核验	`AUTH_FAILED`	`(空) -> auth_failed`	`三要素自动核验失败。失败原因：[e签宝返回的错误（如：身份证号与姓名不匹配）]。合同包转入三要素不一致状态。`
三要素修正	`CORRECT_AUTH`	`auth_failed -> signing`	`修正了签署方三要素信息（[甲方姓名/乙方姓名] 的手机号由 [旧号码] 修改为 [新号码]），重新核验通过并激活了新签署流程。`
内部审批类	`SUBMIT_APPROVE`	-	`将合同包提交至审批流，当前等待 [节点审批人姓名] 审批。`
内部审批类	`APPROVE`	`approving_new -> signingapproving_void -> signing_voidapproving_modify -> signing_modify`	`[审批人姓名] 同意了该合同的 [签约/变更/解约] 申请。审批意见：[审批意见内容，若为空显示“同意”]。`
内部审批类	`REJECT`	`approving_new -> rejected`其他同上	`[审批人姓名] 驳回了该合同的 [签约/变更/解约] 申请。驳回原因：[审批人填写的驳回意见]。`
内部审批类	`ADD_SIGN`	-	`[当前审批人姓名] 邀请了 [加签人姓名] 进行 [前加签/后加签] 共同审批。`
外部签署类	`SIGN`	`signing -> signing` (中间态)	`[甲方姓名/乙方姓名] 已通过e签宝完成电子签名。签署时间：[精确时间]。`
外部签署类	`REJECT_SIGN`	首次签约：`signing -> revoked`/`rejected`补充/解除：`signing_xxx -> completed`	`[甲方姓名/乙方姓名] 拒绝了签署邀请。拒签原因：[客户填写的拒签理由]。`
企业落章	`SEAL`	`signing -> completed`	`丙方授权盖章人 [盖章人姓名] 经人脸核验通过，成功加盖企业公章，完成最后落章归档。`
延期控制	`DELAY`	`signing -> signing`	`申请了对合同包的延期，延期天数：[X]天。新的签署截止日期为：[新日期]。`
撤销/重签	`REVOKE`	`signing -> revoked`	`撤销了该合同包的首次签署流程。撤销原因：[撤回原因]。系统将锁定该房源 2 小时以供重新发起。`
到期失效	`EXPIRED`	`signing -> signing` (超期弱提示)	`系统检测到已超过设定的签署截止时间 [截止时间]，客户签署链接已失效。`
合同变更	`MODIFY_APPLY`	`completed -> approving_modify`	`发起了合同变更申请。变更原因：[变动内容描述]。系统将生成补充协议签署流程。`
合同解约	`VOID_APPLY`	`completed -> approving_void`	`发起了合同解约申请。解约原因：[解约原因描述]。系统将生成解除协议签署流程。`
解约完成	`VOID_COMPLETE`	`signing_void -> voided`	`双方已完成解除协议签署。合同包正式作废，本地 PDF 副本已加盖“已解除VOID”防伪水印，房源锁定已自动释放。`

十八、前后端质量验收指标

18.1 前端 (Frontend) 验收指标

风控逻辑无死锁：在门店签约配置中选择“先签后审”时，“自动落章”选项强制禁用，落章模式自动选中并锁定为“手动落章”。
表单拦截规范：发起签约时，若买卖成交价/租赁租金 ≤ 0，或买卖双方/租赁双方三要素输入为空/不合法，点击提交时必须强行拦截。佣金双零时应当正常放行，且不生成任何佣金确认书。
三要素强拦截阻断：发起签约时如果核验不通过，界面必须弹窗阻断，且绝对不提供任何“强制提交/绕过校验”的勾选框和参数接口。
天数延期校验算法：打开合同详情延期弹窗，系统需根据当前时间与发起时间的生存期校验延期天数是否符合“不超过30天绝对上限”，若超出，快捷按钮必须自动隐藏。
子Tab切换与显隐：核验 PC 端合同详情抽屉中，在“合同预览和签字进度”Tab下切换 首次签署(first)、合同变更(modify)、合同解约(void) 子页签时，对应的子模块是否能正常动态显隐且内容无重叠或溢出。
移动端导航与页面规范：移动端合同详情页面底部操作栏展示为纯文字按钮，不带图标以增强触控交互；点击详情、审批意见时均采用全屏页面跳转，严禁使用半屏底部抽屉承载全页面级的数据。

18.2 后端 (Backend) 验收指标

强校验阻断：在 /api/contracts/initiate 发起签约接口中，必须强制校验三要素核验是否通过。若未通过，必须抛出 400 Bad Request 并阻断流程，严禁由于接口超时等原因降级放行。
用印安全锁拦截：手动落章接口 /api/contracts/seal 接收到用印请求时，必须校验对应的合同包内部审批是否已通过。如果审批未完成或已驳回，接口必须拒绝调用e签宝用印API，并返回 422 Unprocessable Entity 错误提示。
物理作废数据一致性：当内部审批驳回、撤销或解除协议签署完成时，后端必须在更新本地合同状态的同时，同步调用e签宝API物理作废该流程，并利用 Webhook 状态保障数据强一致。
延期天数上限控制：后端修改有效期限接口必须再次校验延期后截止时间自发起之日起是否 ≤ 30 天，若超出，必须抛出异常。
无特批线下作废接口：后端代码中必须彻底删除 /api/admin/contracts/offline-void 接口，API 接口测试时请求此路径必须返回 404 Not Found。

十九、行业术语与英文定义对照表

中文术语	英文对照 / 编码	业务解释
合同包	`contractPackage`	一次交易中生成的所有子合同及附件的逻辑集合。有唯一的 `packageId`
签署流程	`signFlow`	e签宝端的物理流程实体。一个合同包在e签宝端对应一个 `flowId`
先审后签	`approve-first`	内部审批通过之后，系统才调用e签宝API向外部客户下发签署通知的业务模式
先签后审	`sign-first`	系统直接发起签署通知外部客户，外部客户双签后，再进入丙方内部审核的业务模式
自动落章	`auto`	签约各方签署完毕后，系统静默自动调用丙方电子印章在合同上落章归档
手动落章	`manual`	签约各方签署完毕后，必须由丙方被激活的盖章人手动确认并人脸核验后才能落章
用印安全锁	`seal-security-lock`	在先签后审模式中，内部审批未终审通过前，禁止盖章权限人加盖公章的控制逻辑
三要素	`three-factors`	用于校验自然人身份真实性的姓名、身份证号、手机号

房产经纪SaaS系统 · 在线签约功能

文档阅读指南

目录

第一部分：业务全景与时序

第二部分：前置准备与策略配置

第三部分：发起签约流规范

第四部分：签约执行与用印安全锁

第五部分：全端合同与审批交互规范

第六部分：技术指标与质量验收标准

第一部分：业务全景与时序

一、 项目背景与设计目标

1.1 背景说明

1.2 核心目标

二、 系统集成拓扑架构

三、 核心业务流程图

3.1 首次签约完整流程

3.2 合同变更与解约业务流程 (补充协议/解除协议)

第二部分：前置准备与策略配置

四、 签约主体与授权盖章人管理

4.1 签约主体维护

4.2 盖章授权人控制

五、 合同模板分类维护与自定义字段

5.1 模板分类

5.2 列表降噪与详情下沉

5.3 模板自定义动态字段输入规则

六、 门店电子签约策略配置

6.1 门店配置与联动控制

6.2 签署限制参数

第三部分：发起签约流规范

七、 买卖与租赁合同包生成规则

7.1 二手房买卖合同包生成矩阵

7.2 房屋租赁合同包生成矩阵

7.3 免责性绝对金额明示

八、 三要素前置同步核验机制 (强阻断无强发)

九、 签署中异常状态自助修正重发机制

第四部分：签约执行与用印安全锁

十、 先审后签与先签后审落章机制

10.1 先审后签模式

10.2 先签后审模式

十一、 内部审批决策流 (会签一票否决与加签)

11.1 通用审批流规则可视化配置与编排

十二、 用印安全锁：先签后审手动落章强校验控制

十三、 中途撤销与已签状态下的物理作废机制

十四、 合同变更(补充协议)与合同解约(解除协议)流程

第五部分：全端合同与审批交互规范

十五、 桌面端合同管理中心与详情抽屉交互

15.1 详情抽屉版式与滚动区域

15.2 详情子页签与显示模式

十六、 移动端合同与审批管理交互

16.1 页面排版与跳转

16.2 底部操作按钮与延期交互

十六点五、 桌面端全局操作日志审计中心交互规范

16.5.1 高危审计事件微型看板

16.5.2 复合过滤检索

16.5.3 日志数据表格与防篡改警告

16.5.4 CSV 报告审计导出

第六部分：技术指标与质量验收标准

十七、 操作日志存证与哈希防篡改规范

17.1 操作日志审计流水内容清单与具体描述规范

(1) 每一条操作日志必须包含的基础字段类型

(2) 审计流水日志具体触发场景与文案模板一览

十八、 前后端质量验收指标

18.1 前端 (Frontend) 验收指标

18.2 后端 (Backend) 验收指标

十九、 行业术语与英文定义对照表

一、项目背景与设计目标

二、系统集成拓扑架构

三、核心业务流程图

四、签约主体与授权盖章人管理

五、合同模板分类维护与自定义字段

六、门店电子签约策略配置

七、买卖与租赁合同包生成规则

八、三要素前置同步核验机制 (强阻断无强发)

九、签署中异常状态自助修正重发机制

十、先审后签与先签后审落章机制

十一、内部审批决策流 (会签一票否决与加签)

十二、用印安全锁：先签后审手动落章强校验控制

十三、中途撤销与已签状态下的物理作废机制

十四、合同变更(补充协议)与合同解约(解除协议)流程

十五、桌面端合同管理中心与详情抽屉交互

十六、移动端合同与审批管理交互

十六点五、桌面端全局操作日志审计中心交互规范

十七、操作日志存证与哈希防篡改规范

十八、前后端质量验收指标

十九、行业术语与英文定义对照表